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Editor’s Notes 


This issue of "The Heap" contains numerous small items, 
which I hope will be of some interest to you. As usual, I have 
included some items from the last symposium, in New Orleans, for 
those of you who couldn’t get there. These include VAX Ada field 
test reports, and the slides from a talk on TPU programming tech¬ 
niques . 

Also in this issue is a list of errors from the TeXBook, 
second edition. If you are a user of TeX, this should prove 
valuable, and if you're not a user of TeX, you should be. 

Kathy Hornback, our esteemed SIG Chair, has submitted an ar¬ 
ticle summarizing the results of the last Wishlist survey, and 
DEC’S response to the top vote getters. Along with this, Alan 
Rizzuto has submitted the form for starting the next iteration of 
the wishlist survey. Alan has kindly taken over this function 
from me, I hope you will help him with the process by submitting 
items. I know he will be more organized about the whole affair 
than I was. 

Finally, I have included a number of letters which may be of 
interest to our membership, including a response to the Fortran 
8X material. That material was probably our hottest topic in New 
Orleans; watch this space for future developments. In particu¬ 
lar, we will probably be including a questionnaire sometime soon; 
at the request of the Fortran 8X standards group. 

This will probably be the final issue of "The Heap" as you 
now know it. The DECUS Management Council has voted to combine 
the various SIG newsletters into a combined publication. I and 
several others have been adamantly opposed to this, but the old 
saying about fighting City Hall holds true. There comes a time 
when you've got to admit you've lost, and make the best of the 
situation. If all the rosy predictions for the combined 
newsletter come true, you should be better served in the future, 
so lets hope for the best. In any case, I hope that over the 
past year I have provided you with useful and interesting infor¬ 
mation. I will continue to try to do so under the new format al¬ 
so. As usual, I welcome any comments or suggestions. My address 
is: 


Alan L. Folsom, Jr. 

Dept 431, Fischer & Porter Co. 
E. County Line Road 
Warminster, Pa. 18974 
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Al Note 


Special SIGART Issue dn AI in Engineering 
The SIGART newsletter* a quarterly puelicatidn df the ACM special 

T NTEREST * 6RDUP DN ARTIFICIAL INTELLIGENCE* CONTINUES TD BE AN EXCELLENT 
SOURCE FDR INFORMATION ON "PEAL WORLD" A I PROJECTS- The APRIL ISSUE CNo. 

J CONTAINS A NINETY PAGE SURVEY OF THE PRESENT STATUS OF RRTIFICIAL 

Intelligence as applied to engineering. The authors of the survey are D. 

Sriram anii R. Joofbani of CMU. Dr. Sri ram was the compiler of the extensive 

PI BIBLIOGRAPHY WHICH WAS PUBLISHED IN THE LAST ISSUE OF "The HeAF". QUOTING 
FROM THEIR INTRODUCTION* 

"The papers in this special issue were compiled from responses to 

THE ANNOUNCEMENT IN THE JULY 1984 ISSUE OF THE SIGART NEWSLETTER AND 
NOTICES POSTED OVER THE ARPANET. THE INTEREST BEING SHOWN IN THIS AREA IS 
REFLECTED IN THE SIXTY PAPERS RECEIVED FROM OVER SIX COUNTRIES." 

Expert systems form the largest group of systems in the survey? but 
causal knowledge representation and natural language processing are also 
surveyed. There is a section describing tools fdr the af-plicattion of RI to 

ENGINEERING* AS WELL AS A SPECIAL SECTION DEVOTED TO GROUPS DEVELOPING MORE 
THAN ONE APPLICATION. HERE IS THE COMPLETE LIST OF APPLICATION AREAS COVERED! 

Causality 

Control 

Databases'Manasement 

Design (this was the largest group* reporting on £3 design systems) 

DlAGNOSIS 

Education 

Groups involved in several projects 
Interpretat i on 
ManufacturiNG 

MISCELLANEOUS 

Natural Language 

REPAI R/f1ft I NTENANCE 

Simulation 

Tools 

The authors promise a future update to the survey* and draw 

ATTENTION TO THE "FIRST INTERNATIONAL CONFERENCE ON APPLICATIONS OF 

Artificial Intelligence to Engineering Problems" which will be held April 15-18* 
1986* at Southampton University* England. For more information about the 
CONFERENCE * CONTACT S 

D. Sriram* Technical Chairman First RIEP 
Civil Engineering 

and Construction Robotics Laboratory 
Department of Civil Engineering 
Carnegie-Mellon University 
Pittsburgh* PR 15813 

SR I RAM(?CMU*R I -c I VE . ARF A 


Working ... 
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June 4, 1985 

The L&T Newsletter 
C/0 A1 Folsom 
Fisher and Porter 
East County Lane Road 
Warminster, Pa 18974 


Dear Al: 


VAXintosh Futures 


James Downward 
VAXintosh Working Group 
C/0 KMS Fusion, Inc 
P.0. Box 1567 
Ann Arbor, Mich. 48106 
(313)-769-8500 

At the Spring DECUS meeting the VAX SIG and the Languages and Tools SIG 
seem to have jointly formed a VAXintosh Working Group. Yes, you heard right, a 
"VAXintosh". Not surprisingly, there is a lot of interest among the DECUS 
membership in providing MACINTOSH like functionality for VAX systems and DEC 
systems in general. 

At the "Just a Modest Proposal" session on Monday night, I presented a 
proposal that DEC needed a VAXintosh-like machine. The proposal was well 
received by the VMS community. That night I talked long into the morning hours 
with the software engineer in charge of the DEC user/machine interface for the 
VAXstation. It was quite clear from this conversation that DEC was very 
interested in the issue and wanted significant user input to help define what 
the needs, requirements, and market place for such product were. 

Consequently on Wednesday, A BOF session on "VAXintosh Futures" was held 
with close to 100 attendees. It was soon realized that a VAXintosh represents 
a rather complicated, multi-faceted issue. Consequently, we propose to develop 
a working paper for presentation to DEC outlining in some detail what ve mean 
by a VAXintosh. Topics which must be addressed include both hardware and 
software requirements and the general philosophy for the user/machine 
interface. Topics which we feel need to be addressed include: 

o Market segments to be addressed by the VAXintosh. Why is it needed? What 
users would benefit most from a VAXintosh and vhy? 
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o Specific hardvare requirements. Would just a cheap desk-VAX do, or is more 
needed? This includes graphic resolution, graphic display speed, 
ergonomics, input device (mouse?), local intelligence, and computer port 
I/O speed. 

o User/Machine Interface. Is a MAC-1ike, icon driven interface vhat is 
needed? If so, must it mimic all of DCL or just a subset? 

o User software development tools for a VAXintosh. Is an extension of SMG 
adequate to provide the functionality needed? Is a "Quick-Draw"-like 
interface needed. Vhat about a special CLI to map MAC-like icon commands 
into DCL commands, or possibly extensions of the CDU to include ICON 
commands so that utilities could work both from an icon driven interface or 
from a DCL interface? 

o DEC-supplied VAXintosh software. Are DEC equivalents of software packages 
like MACwrite, MACdraw, etc. needed for the VAXintosh or will user 
developed software suffice (if the interface and development tools exist)? 

o MAC-Specific issues. Should DEC have a DECnet-MAC software product (they 
have a DECnet/MS-DOS product) or an interconnect to AppleTalk? Should DEC 
offer additional support for the MACINTOSH as a VAX terminal? 


As you can see the issues are rather complex and we have a significant 
amount of work to do if we are to address these issues adequately to make an 
impact on DEC within the appropriate time window. Numerous attendees at the 
BOF session, have volunteered to write mini-working papers on one or more of 
the above subjects. I have volunteered to gather these papers and try to 
hammer them into a coherent whole (throwing in ay own ideas also, of course). 

However, we don't want to limit the input to this effort to the people who 
attended the BOF. Input from as many sources and points of view as possible is 
needed. Consequently, if you are interested in "VAXintosh Futures", write down 
your thoughts, proposals, or design goals and send them to me. 

If we get enough input and support from the VMS community, by Fall, the 
VAX and Languages and Tools SIGs can jointly present DEC with a detailed 
working paper proposing what we would want in a VAXintosh. Currently, we have 
some support within DEC for a VAXintosh in some form. They have a "gut level" 
feeling that something is needed but are not sure quite what. This gives the 
VMS community a significant "window of opportunity" to influence DEC software 
and hardware product management when it counts. 


Sincerely, 
James Downward 
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AIVIAX ENGINEERING AND MANAGEMENT BERVICEB COMPANY 

A Subsidiary o( AMAX Inc. 

1707 COLE BOULEVARD • GOLDEN. COLORADO 80401 • (303) 234-9020 


June 13, 1985 


DECUS Languages and Tools SIG 
Mr. Alan L. Folsom, Jr., Editor 
Dept. 431 

Fischer & Porter Company 
County Line Road 
Warminster, PA 18974 


A Programmer's Response to May 1984 F0RTRAN-8X FIB-1 
and the DEC and IBM Objections to Publication Therof 


I am deeply disappointed by the negative responses to F0RTRAN-8X which were 
expressed by the vendors, and which probably are representative of their 
customers. In a nutshell, the FORTRAN Committee is being asked to preserve 
nearly all of old FORTRAN in any new FORTRAN. What a shame. In the name 
of “upward compatibility", we are to be shackeled to dinosaurous language 
constructs that hobble the progress of programming practice and profes¬ 
sion. Today's and tomorrow's programmers are to be mired in the tar pits 
of decades-old source code, and denied the ability to exploit and even 
propel the astonishing progress in hardware technology all around. As a 
programmer with over fifteen years' use of the language. I'm ready for a 
new, even radical if need be, departure from this venerable-but-musty old 
syntax. To the preservationists, I say "Your insistence on fossil-code 
compatibility is holding us down!" 

It's very clear, for instance, that the WHERE construct and the array 
operations proposed in F0RTRAN-8X FIB-1 facilitate some safe, simple, and 
unambiguous compilations into parallel-processor code. (Is it sinister, or 
mere coincidence that neither vendor is vanguard in parallel processing?) 
If WHERE and arrayops are written off as too "not demonstrably compatible" 
with existing FORTRAN, we will lose our best hope for orders-of-magnitude 
performance improvements for the sake of programs punched on 026's. 

Computer vendors tend to see language changes in terms of extensions. That 
is how we get tied to particular brands in spite of standardized languages. 
Every vendor's FORTRAN-77 has its own set of extensions, and any program 
using those extensions suffers in portability to another computer model. 
As a result, the vendor is more familiar with tacking on Incremental 
enhancements than writing a whole new compiler. Such methodology is costly: 
in the name of old-syntax compatibility, DEC-20 FORTRAN-77 is only this 
summer finally fleshed out; I would have been much happier to have a com¬ 
plete DEC-20 FORTRAN-77 implementation as early as the new VAX product came 
out, even if compatibility was compromised. (I understand that compati¬ 
bility was what DEC-20 user representatives asked for; I think some 
leadership should have steered them away from that tar.) 



Ultimately, compatibility is ridiculous, and doomed. Where would we be if 
a standards body had decreed that the next generation desktop hardware had 
to be 6502-compatible? Or, if no VAX were permitted that could not boot-up 
from a PDP-11 disk? The competition to FORTRAN is PASCAL; if FORTRAN 
cannot Incorporate modern language constructs, it will end up abandoned, 
untaught, and unbought. I would much rather convert to a new, strong 
FORTRAN than have to abandon it all and go to another language. Yet there 
I am headed. If preservationists have their way. 

Source-level compatibility is an Issue for the myopic. Given an adequate 
filter program (which should be a part of the standard), I could even 
continue to write in FORTRAN-77 and use F0RTRAN-8X. Surely it's easier to 
write a 77-to-8X filter than it is to write an 8X-and-77-and-66-and 
extensions compiler! Let the languages be Incompatible; just give us the 
bridge out of one language and into the next. 

Where are we going? New languages are incorporating good features of 
others. New TrueBASIC resembles PASCAL more than BASIC; I think that's to 
the better. If I'm not mistaken, F0RTRAN-8X is learning a few tricks from 
APL; I would love to gain APL power without having to relearn operator 
precedence. New computer language constructs seem to be converging on 
psuedocode structure and higher-level abstractions. If we can just slough 
off some of the old baggage, our new languages can also become less complex 
and costly, more simple, effective, and economical. 





Peter F. Klammer 
Mineral Systems Development 


/sm 
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TEXbook Bugs 

Bag$ in The TtfCbook, $econi printing 1 


This is a list of all corrections made to The Tj^Kbook since the second printing. 
If your copy doesn’t say *Second printing (October 1984)' on the copyright page, 
yon should also look at the previous bug list. In fact, the most important cor* 
sections to the first printing were discovered first, so they’ve already been made. 


Page 23, line 16 

MUMULJ] 

Tfcla la TaZ, Varaloa 1.0 (praloadad format*?lain 

83.7.16) 

Page 33, line 32 

(10/21/84) 

The bottom line shows how far IfcjX has gotten until now in the story 

Page 67, append a new exercise 


£><£>*■ EXERCISE 11.6 

X i Construct a \frac macro inch that ‘\frael/2' yields *•/,’. 

Page ISO, line 15 

mtfuiwi 

•y’”_s*g’*2$ i4" + if 7 

Page 194, lines 13-15 should be centered better 

n 


(i) 

if x s p then p = x; 

(2) 

if x = y and p s x then x = z. 

(3) 

Page 215, lines 9 and 10 from the bottom 

WEJEHm 

general format is the same as for \daf and \gdaf, but T^X blindly expands the tokens 
of the replacement text according to the expansion rules above. For example, consider 

Page 233, lines IS-19 

(1/19/85) 

Weight Servingr Approximate Cooking Time * 

8 lbs. 6 1 hour and 50 to 55 minutes 

9 lbs. 7 to 8 About 2 hours 


0*/a lbs. 8 to 9 2 hours and 10 to 15 minutes 

10*/t lbs. 9 to 10 2 hours and 15 to 20 minutes 


Page 236, lines 18-21 

(1/19/85) 


Squab 

Pousrin 

2 

•/* to 1 

Broil, Grill, Roast 

Broiler 

Poulet Nouveau 

2 to 3 

1 '/» to 2 >/, 

Broil, Grill, Roast 

Fryer 

Poulet Reine 

3 to 5 

2 to 3 

Fry, Saute, Roast 

Roaster 

Poularde 

5 */» to 9 

Over 3 

Roast, Poach, Fricassee 


(This change should also be made at the bottom of page 237.] 
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Bug$ in The T^Xbook, eeeoni printing 


Page 256, fifth-last line 

(1/10/85) 

fquab4Peuseia*2*\frac3/4t to lkBroil, Grill. ftoast\cr 

Page 237, line 25 

(10/10/84) 

saying *\tabskip*(glue)’. For example, let’s do the poultry table again, but with the 

Page 280, lines 7 and 8 

(1/8/85) 

(4-bit number). The specified output stream is opened or closed, for use in \writo 

commands, as explained in Chapter 21. 


Page 300, lines 5-10 [changed for version 1.3] 

unmisi 


what part of 1£X’8 memory has become overloaded; one of the following fourteen things 
will be mentioned: 


annber of strings (names of control sequences and files) 
pool oiao (the characters in such names) 

■ain aonory oiao (boxes, glue, breakpoints, token lists, characters, etc.) 


Page 300, lines 23-29 [changed for version 1.3) _ (11/25/84) 

f lf you have a job that doesn't overflow TfcpC’s capacity, yet you want to see 
just how closely you have approached the limits, just set \traeingstato to 
a positive value before the end of your job. The log file will then conclude with a 
report on your actual usage of the first eleven things named above (i.e., the number of 
strings, ..., the save size), in that order. Furthermore, if yon set \traeinf stats equal 
to 2 or more, TfcpC will show its current memory usage whenever it does a \shipout 
command. Such statistics are broken into two parts; ‘490*6980’ means, for example, 
that 490 words are being used for “large” things like boxes, glue, and breakpoints, 
while 5950 words are being used for “small” things like tokens and characters. 


Page 305, line 26 


sentable as “*14. Asking TfcpC to \shov\““M produces the response 4 > \**M=stcro: ->\i> ’. 

Page 308, line 25 

(3/25/85) 

\def \appendronan#l#2#3{\edef#l{\defVneexpand#l{\csnane 


Page 311, insert a new answer 

(1/19/85) 


11.6. \dsf\frae#l/92<\lsaTSTBods\ksrn.lsn 

\raiss. 6*x\hbox{\ths\seriptf onto il}\ksrn-. lsn 
Akarn-.16tn\lov*r.25ex\hbox{\the\seriptfontO#2}> 

[This causes answer 12.8 to move to page 512; answer 12.16 also moves to page 513.] 
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Bug$ in The T&Cbook, eeeoni printing 3 


Page 327, lines 26-33 _ (10/22/84) 

10.16. M\displaylins*{\hf ill xXequir x;\hfill\llap{(l)}\cr 

\hiill\hb*x{il}Xquad x\«quii y\qntd\hb«x{tk«B>\qnad 
y\*quir x;\hfill\llap{(2)}\er 
Xhiill\hbox{if}\quad x\*quiT y\quad\hbox{and}\quad 
y\tquiT s\quad\hbox{thtn}\quad 
x\aquiT s.\hfill\llap{(3)}\er}$t 

There’* also a trickier solution, which begin* with 

M\di*playlin**{x\aquiTx;\hfil\llap{(l)>\hfilaag\er 


Page 332, lines 17-24 ___ (1/19/85) 

X**ttabs\*\ind«ntU0\frael\2 lba.\qquadl\it 8arring*\qquadl\er 
X+l\n*gthinspae*\it VeightlXit Strringsl 
<\it Approximate Cooking Tiao\/>*\cr 
<i*aall*kip 

\+k& lba. 1611 hour and 50 to 55 ainutesXer 
X*19 lb*.17 to SAAbout 2 hour*\cr 

X+19\fracl/2 lb*. 18 to 912 hour* and 10 to 16 ninuto*\er 
\*U0\fracl/2 lb*.19 to 1012.hour* and 15 to 20 ninuto*\cr 


Page 332, lines 33-35 _ (1/19/85) 

proofs. (You weren’t supposed to think of this, but it has to be mentioned.) See 
exercise 11.6 for the l \tr ac’ macro; it’s better to say than 4 |’, in a cookbook. 

Another way to treat this table would be to display it in a vbax, instead of 
including a first column whose sole purpose is to specify indentation. 


Page 857, lines 85 and 36 

(1/8/85) 

Vd*f\*{\diseratioaary{\thinspac*\th*\t*xtfont2\char2HH}} 

Page 357, last two lines 

(4/17/85) 

VdefNprfinfisCXifx’XnaxtMatXnaxtXprCfifisVelaoXifx^XnextMetXnextXprllCt 

\.l..\l.t\n.xt\.greup\fi\fi \n.xt} 

\d.f\pr«CC.«l{\priae.} \d.f \prfi00t«l«3{*2\.group> 


Page 358, lines 8-12 

(1/23/85) 


\def\hbar({\aathchar*26\ak*rn-9Buh}} 

\d*f\*urd{{\nathehar H 1270» 

\d*i\angl*{{\Tbox{\ialign{$\n€th\script*tyl*#tt\ercr 

\no t \nathr a 1{ \ nks rn 14nu> \ cr c r \no al i gn{\no int ar 1 in* skip} 
\ak*m2.6nu\l*ad*r*\hrul* height .S4pt\hfill\nk*rn2.6Bu\ercr»» 


10 










4 Bug$ in The TtfCbook, eeeoni printing 


Page 359, lines 7-8 

\dsf\ddtt s{\nathinnsr{\nksnilBu\rniss7pt\Ybox{\ktrn7pt\hbox{. >}\nksra2mu 


\rais«4pt\hbox{ .}\nksrn2nu\rai»slpt\hbox{ .)\ik*rnliu» 


Page 360, line 22___ (1/22/85) 


\akarn5BU \raist.6\dinsnC\copy\rootbox \mksrn-10nu \box0} 


Page 861, line 3_ (3/27/85 


\dnf\buildrsltl\oT«ri2{\Bathrsl{\aathop{\knrn0pt#2}\liaits~{#l}}} 


Page 361, lines 19-20_ (1/22/85) 


Ydai\baod{\askip-\nadauskip \akirn5au 

\nathbin{\m aod> \ponalty900 \mksrn5nu \nskip-\aadsuskip} 


Page 361, line 27___ (5/1/85) 


\d«f\aatrix#l{\attll\•\TetnterC\noraalbastllBtt\a€th 


Page 361, bottom line___ (5/1/85) 


\aull\;\Tbox{\k«rn\ht1\box2}\andfroup> 


Page 362, line 9_____ (5/1/85) 


NdifXiq&llptKXBttllXAfciBtiHXopiBuplXjotXBOth 


Page 364, line 3 __(3/23/85) 


\dsf \plainoutput{\thipout\Tbox{\aakahaadlina\pagsbodj\Bakofootli&t}l 


Page 399, eighth-last line 


\bastliattkips\footnotsba§slinaskip\noi&dsnt\unhboxO\par} 


(2/11/85) 


Page 401, line 5 _ (1/29/85) 

\fontdinsnparameters to qualify as a math symbol font). (2) Set all the font identifiers 


Page 414, line 10 _ 

\font\titlsfont*cnssdc40 




X title* la ehapter •pining* 


Page 444, bottom line 
depth d(z) + v, consisting of box * followed by an appropriate kern followed by booc z. 
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B%g$ in The TfiXbook, icconi printing 5 


Page 466, left column _ (1/19/85) 

fractions, *7,139-143, 132, 170, 179, 

133, 444-443. 
huge, 199. 

dashed form, 97,139-140, 233, 239. 

Page 4T0, index entries for Uonglaf tarrow thru \Longrightarrow (10/5/84) 
The reference to page 358 should be underlined (seven times). 

Page 475, index entry for punctuation in formulas _ (4/29/85) 

Add a reference to page 191. 

Page 478, first and last lines _ (10/11/84) 

Delete the last line in the right-hand column (since it appears on page 479), and add 
the following line at the top of the left-hand column (since it was dropped by mistake 
from the second printing): 

styles of math formatting, 140-141, 441-447. 


Page 478, tabskip entries 

(3/25/85) 

Instead of ‘237-239’ and ‘237-238’ it should say ‘237-239’ twice. 

Page 483, lines 16-17 

(1/19/85) 

P.O. Box 0606 


Providanca El 02940-9506, USA. 


Page 483, lines 22-23 

■KH3Z31 


P.O. Bax 9506 

Providence RI 02940-9506, USA. 
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TPU 

PROGRAMMING 

TECHNIQUES 


SEARCHING 


• USE EXACT SEARCHES INSTEAD OF NO—EXACT 
SEARCHES WHERE POSSIBLE 

• FORWARD SEARCHES ARE SLIGHTLY FASTER THAN 
REVERSE SEARCHES 

• USE $£AJ?CM(PATTERN_VARIABLE) INSTEAD OF 
SEAffCfKPATTERN EXPRESSION) 

• USE ANTfABC') INSTEAD OF 'A'l'BTC' 
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SEARCHING 


USE ANCHORED PATTERN SEARCH TO LOOK FOR 
TEXT ON CURRENT LINE INSTEAD OF LOOKING AT 
EACH CHARACTER 

USE PATTERNS ALONG WITH OTHER TPU FUNCTIONS 


SEARCHING 


I check if a particular pattern Ilea within col 1 to 60) 
PROCEDURE TEST 

nhltoapaco :•••♦• ■; I apace ♦ tab 

P*6*-P*t :• •!• h SPAM (whitespace) 6 ’Page • i REMAIN; 
ooarch_range:• SEARCH(page_pat,forward); 

FOSITION(search_range); 

|F (Crr.IMFO (current.bof f er, ‘offset colon") >■ 1) 

TOR 

POSITION (END.OF(search.range)); 
IF(GET_IHPO(cnrrant_baffor,"offset_colwao") <■ 60 ) 

THEN 

POSITION(search_range); 

RETURN 

ENDIF; 

ENDIF; 

ENPPROC EUU RE 
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USING THE LANGUAGE 


• USE IF (EXP) INSTEAD OF IF (EXP) * 1 

• USE IF MOT (EXP) INSTEAD OF JF(EXP) * 0 

• USE ON-ERROR TO CATCH ERRORS INSTEAD OF 
CHECKING RESULTS OF FUNCTIONS 


MM* II 


USING THE LANGUAGE 


Frocsdort STRIP 

LOCAL iMrchpftt, attrclLraiigt; 

on.error 

return t nil done (when EOB or search falls) 

Mdos.«ZTor; 

searchpat :■ SPARC ' • ) k LIRE_ERD; I Batch trailing spaces or tabs 

LOOP 

search.range :• 8EARCH (searchpat.forward); 
position(beginnlng_of(search_range)); 
erase.character(1ength(search_range)); 

BMDLOOP; 

BRDP R OCEP U RE 
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USING THE LANGUAGE 


• MOVE MARK AND CREA TEJRANQE FUNCTIONS 
OUT OF LOOPS WHERE POSSIBLE 

• MOVE SUBSTR OPERATIONS OUT OF LOOPS 
WHERE POSSIBLE 

• USE THE CASE STATEMENT INSTEAD OF NESTED 
IF-THEN-ELSE WHERE POSSIBLE 

ORDER OF MARKER VARIABLES IS IMPORTANT FOR 
RELATIONAL OPERATORS 


USING THE LANGUAGE 


• DELETE CONTENTS OF GLOBAL VARIABLES WHEN 
NO LONGER IN USE 

• AVOID RUNNING THE COMPILER INADVERTENTLY 

• USE ACTUAL VARIABLE NAMES INSTEAD OF 
CURRENT .JC BUILT-INS 
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USING THE LANGUAGE 


• AVOID NUMEROUS LOCAL DECLARATIONS IN 
FREQUENTLY CALLED PROCEDURES 

• STORE STRING VARIABLES OF USED REPEATEDLY) 
IN GLOBAL VARIABLES 

PROCEDURE CALL OVERHEAD IS MINIMAL FOR 
PROCEDURES WITHOUT ARGUMENTS 


BUFFER MANAGEMENT 


• DELETING A BUFFER CAN BE VERY COMPUTE 
BOUND 

• CREATE BUFFERS ONLY WHEN NECESSARY AND 
ERASE BUFFER CONTENTS WHEN NO LONGER 
NEEDED 

• USE COPY OR MOVE TEXT lO MOVE LARGE 
BLOCKS OF DATA INSTEAD OF A SELECT RANGE 

• (USE MAXJUNES BUFFER SETTING TO CONTROL 
BUFFER GROWTH) 
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EXTENDING EVE OR EDT INTERFACE 


• READ CHAPTER 5 (REFERENCE), CHAPTER 6 (EVE), 
CHAPTER 10(EDTEM) 

• NO PERFORMANCE PENALITY FOR HEAVILY 
COMMENTED PROGRAMS 

• CONVERT A GROWING COMMAND FILE INTO 
SECTION FILE 

• REMOVE UNUSED PROCEDURES FROM YOUR 
SECTION FILE 


EXTENDING EVE OR EDT INTERFACE 


• MOVE INFREQUENTLY USED PROGRAMS OUT OF 
YOUR SECTION FILE 

• DYNAMICALLY COMPILE AND EXECUTE 
PROGRAMS WHEN NEEDED 

• VM FOR PROCEDURES IN A SECTION FILE 
CANNOT BE RE-USED IF THE PROCEDURE IS 
REDEFINED 

• DELETE PROCEDURES IF USED ONLY ONCE WHEN 
BUILDING SECTION FILE 
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EXTENDING EVE OR EDT INTERFACE 


• PUT GLOBAL VARIABLE ASSIGNMENTS IN 
PROCEDURE AT THE BEGINNING OF SECTION FILE 

• FEEL FREE TO "REDUCE" INTERFACE BASED ON 
PERSONAL PREFERENCE 


LOW-SPEED TERMINALS 
(< 2400 BAUD) 

• SHRINK YOUR MAIN WINDOW SIZE FOR SLOW SPEED 
LINE USAGE 


DCFIHEJST ('•4]ut.iMM(cnr«t.(lidM,0, *10)', 
> 
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LOW-SPEED TERMINALS 
(< 2400 BAUD) 

• USt OVtBSTMKt EDITING IN THE MIDDLE Of TEXT 
WHERE POSSIBLE 


FtOCEDURE toggle 

XF get.info (current.buffer, •■ode") ■ overstrike 
THEN 

set (insert, current.buffer); 

ELSE 

•et (oreretrlke, current.buffer); 

EHDIF; 

BVDPROCEDURE 

DEFINE.KET('toggle *.ctrl.ujcey); 


LOW-SPEED TERMINALS 
(< 2400 BAUD) 

• TO INSERT LINE OF TEXT. “OPEN" UP A NEW LINE 
FIRST, RATHER THAN PUSH EXISTING LINE OVER 

• USE SET (MESSA GEJFLA OS, 5) WHERE POSSIBLE 

• USE NONE ATTRIBUTE FOR SELECT OPERATIONS OR 
HIGHLIGHT ONLY THE STARTING CHARACTER OF THE 
SELECT RANGE 
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WINDOWING 


• USE MINIMUM NUMBER OF WINDOWS 

• AVOID OVERLAPPING WINDOWS 

• USE NOME ATTRIBUTE FOR MARKERS AND RANGES 
WHERE POSSIBLE 


WINDOWING 


• KEEP ONE BOUNDARY OF YOUR MAIN WINDOW AT 
THE TOP OR BOTTOM EDGE OF SCREEN 

• USE UPDATE,SCROLL,REFRESH,SHIFT WINDOW ONLY 
WHEN NECESSARY 

• USE TIMER MESSAGE ONLY WHEN NECESSARY 

• USE “SECTION" MOVES INSTEAD OF AUTOREPEATING 
ARROW KEYS WHERE POSSIBLE 
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READING INPUT 


• USE BEAD JUNE INSTEAD OF PROGRAMMABLE 
COMMAND WINDOW WHERE POSSIBLE 

• USE BEAD-KEY INSTEAD OF BEAD-CHAB WHERE 
POSSIBLE 

• USE DEFINED KEYS INSTEAD OF COMMAND LINE 
MODE 


MM* 19 


MISCELLANEOUS 


• USE TPU AS m KEPr EDITOR INSTEAD OF INVOKING 
TPU MULTIPLE TIMES TO EDIT MULTIPLE FILES 

• USE EDIT/TPU/NOCOMMAND IF A COMMAND 
FILE IS NEVER USED 

• DO CBEA TE—PBOCESS ONCE , NOT ONCE PER 
DCL COMMAND I 
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VAX™ Ada® 
FIELD TEST REPORT 


Bevin Brett 
VAX Ada Project 
DIGITAL 


Tl * VAX Is a trademark of Digital Equipmtnt Corporation 

<5) Ada is a registered trademark of the U.S. Government, 
Ada Joint Program Office 


85APR26 


I. FIELD TEST - 

AHD MAGNITUDE 

DURATION 

Duration 

FT1 officially started 

•1-Mov-1984 

kits sent out 

10-Hov-1984 (Approx) 

FT2 started 

•8-Feb-1985 

SDC code freeze 

08-Mar-1985 
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I.A FIELD TEST - DURATION 

AND MAGNITUDE 

Magnitude 

20 FT sites* 

4_000_000 lines of Ada code 
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II. 

OAR SUMMARY 

Nunber of OARS 



Total Closed: 

207 


Total Answered: 

9 


Total Open: 

11 


Total QARs: 

307 
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II. A OAR SUMMARY 

(COHT'D) 


Breakdown of Closed QARs by Category 

Number Total St 

Fixed in next release: 

107 

34 

Inquiry: 

68 

22 

User error: 

38 

12 

Suggestion: 

23 

8 

Documentation error: 

19 

6 

Mot reproducible: 

11 

3 

Informational: 

4 

1 

Temporary workaround: 

3 

e 

Design change: 

2 

e 

Unsupported: 

2 

e 

Temporary patch: 0 

Total: 287 

e 
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II.c OAR SUMMARY - 

USER ERRORS 


User error* 

• Overloadin* resolution problems* the 

compiler it MUCH better than hunans! 

t Exact reading of Manual on 'intuitively 
obvious* issues 
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11.cl 

QAR SUMMARY - 


USER ERRORS (CONT'D 

• 

People confute run-tine exceptions 

end conpile-tine errors 

• 

Unconstrained records causing 

storage error 
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II. c2 

QAR SUMMARY - 


USER ERRORS (CONT'D) 

• 

Absence of Volatile nakes things 

that look like optinizer errors 

• 

Misunderstandings of I/O and 

Tasking 
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111. R SITE COfUENTS 

Conncnts fron users 

• Inprovencnts 

t Documentation 

• Conversions from other compilers 

• Other 
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III iA 

R SITE COROTS - 


IHPROVEHENTS 

• 

Resources consulted 


- CPU 


- memory 


- 1/0 

f 

Variety of ideas for improviny 
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HI.a2 FT SITE COWOTS - 

IMPROVEMENTS (COHT'D) 

Diagnostics 

C "tone error messages seemed a little 
obscure* 

• *good diagnostics provided by the MAX 
Ada compiler” 

Enhancements 

f Recognize more special cases 
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HI ,a3 FT SITE COMMENTS - 

IMPROVEMENTS (COHT'D) 

Generated code quality 

• Few actual suggestions 

• Already similar to Pascal> PL/I» C 

• Depends on program 

• Recognize more special cases 
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III.*4 

FT SITE COMMENTS - 


IMPROVEMENTS (CONT'D) 

ACS enhencevents 

• 

Better compilation manasement 

f 

Ada command to compile a file for 

which e unit does not yet exist 

t 

Tool to determine the correct order 

to compile a set of files 
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III .a5 FT SITE COMMENTS - 

IMPROVEMENTS (CONT'D) 

More propramninp environment tools 

• Cross reference utility 

• Pretty printer 
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III.B 

' R SITE COMMENTS 


DOCUMENTATION 

• 

•best documentation of any Ada 

product oe've seen" 

9 

"Didn't use very much" 

85APR26 

Hl.ll 

R SITE CONMENTS - 


DOClftNTATION (CONT'D) 

More cxanpleSf especially 

9 

Cotmon Lansuase Environment 

9 

I/O 
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IV GATHERED STATISTICS 

• Nature of source programs 

- size 

- number of lines after generics and inlining 

• Compiler performance 

- working set 

- page faults 

- cpu time 

- elapsed time 

• Compilation library characteristics 

- traffic analysis 
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IV. 

CONCLUSIONS 


• 

1580 pa*e workin* set teens 

about 


rifbt 


• 

Speeds between 258 end 2500 

lines 


per ninutc 


• 

Boon for inprowenent 


• 

More data needed 
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V FIELD TEST CONCLUSIONS 

• Duration adequate because of limited 
range of applications available 

• Not as many N user errors" as expected 

e It's amazing how many bugs you can 
have in a validated compiler! 

• Very few known bugs in the VI compiler 
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VAX Ada® Field Test Panel 


Bob Gable 

Lear Siegler/lnstrument Division 
4141 Eastern Avenue SE MS 121 
Grand Rapids, Michigan 49508 

Spring 1985 DECUS (New Orleans) 


®Ada is a registered trademark of the U.S. Government (Ada Joint Pro¬ 
gram Office). 
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CONCLUSIONS 

• VAX Ada Right Choice for 

— VAX-Hosted Support Software 

- Ada Training (with LSE) 

— Embedded Software 

• Initial Development 

• Module and Function Test 

• Well Integrated with CMS, LSE 

• VAX Ada, VAX LISP ==> 2 8600’s In Cluster 

• The Ada Language 

- Time-Consuming to Learn 

— Efficiency Problems for Real-Time, Embedded Computers 

- Promising Features 
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Lear Siegler Ada Work 
_ Current and Near-Term 

• Previous Languages 

— FORTRAN, JOVIAL. Pascal, assembly lang. ==>.Ada 

• Configuration Management Tools 

• MIL-STD-1750A, Z8002 

• Embedded Flight Computer Software 

— Module, Functional Development and Verification 
- Cross-Targeted Compiler for Integration 
— Support Software (Linker, Assembler) 
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VAX Ada 
Callable-CMS 


• CMS$SHOW_GENERATION 

- Passing Procedure Addresses by Value 

• ROUTINE'ADDRESS attribute 

- DEC provided IMPORT.VALUED.PROCEDURE pragma 

- EXPORT .VALUED-PROCEDURE Pragma Needed 

• CMS Calls User Function with In Out Argument; Expects User to Return 
Status Value; Resorted to FORTRAN call 

• Defining Interface Packages Time Consuming 
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VAX Ada Field Test 
Problems 


1. Ada Language Itself 

2. Many Bugs In Separate Compilation 

3. Using VAX Debugger with Ada More Difficult than with 
VAX FORTRAN (MP u**,) 

4. Compiling Ada Programs in ADASBATCH from LSE Awk¬ 
ward 

5. Fewer Problems than VAX FORTRAN Field Test 
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VAX Ada 

Compilation Speed 


Compiler 

Max. Working 
Set Size 

CPU 

Secs. 

Page 

Faults 

Source 

Lines/Min. 

VAX Ada 

2048 

11 

1087 

502 

Lear 

FORTRAN 

1024 

31 

285 

387 


• VAX Ada Working Set Size 


< 1000 

Too Slow 

1000-2000 

Tolerable 

2500 

DEC’S Recommended Value 


• VAX Ada Runs Quickly, Uses Large Amounts of Memory 
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VAX Ada Field Test 
Mechanics 


• Ada Team Responds Quickly! 

• Daily Review of QAR Data Base 

• Learn from Others’ Problems 

— Dynamic Strings 
— Working Set Tuning 

• Transfer of Files - Not Ideal 
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ACM SigAda Ada Run-Time Environment 

Working Group 


Establish Conventions, Criteria, Guidelines for Ada Run-Time 
Environments; Provide Framework to Evaluate and 
Effectively Use Ada RTS 

• Group is Mixture of Ada Implementers, Users 

• Can Real-Time, Embedded Applications Use Full Ada? «v«. 

emsl systems 7 

• Working Group Consensus 

- DEC Documentation Superb - Especially Implementation Depen¬ 
dent Features of Language, Run-Time System 

- Ada LRM with Interspersed with VAX Ada Features 

- If Only the Cross-Targeting Ada Compiler Vendors Did As Well 


a 
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Language-Sensitive Editor 
Field Test 


• Significantly Aids Programming in New Languages (e.g. 
Ada) 

• Customized LSE for Other Languages 

- JOVIAL 

- Microtec/8086 Pascal 

- SUTeX, WTeX 

- Commonly-Used System Service Calls (from FORTRAN) 

• ‘•Semi-Compatible” with EDT 
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Performance Coverage Analyzer 
_ Field Test _ 

• Embedded Computer Software Functional Test 

— For Path Coverage/Statement Coverage 
- Replaces FORTRAN/JOVIAL/PASCAL-Specific Tools 
— Only Tool To Do This for Ada 

• Support Software 

— For Performance Improvement 
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Languages and Tools Wishlist 
Results and DEC Responses 


- K. Hornbach 
Chair, Languages & Tools 

The Languages & Tools SIG published a wishlist in the February issue of 
the newsletter. The results were tabulated by A1 Folsom and A1 Rizzuto, 
and forwarded on to DEC. DEC responded to the Wishlist items at the New 
Orleans Symposium. The following are their responses, based on notes I 
took in the session. I have attempted to make them as accurate as possible, 
but please remember that all the usual disclaimers apply. 

1. DEC should make all VAX manuals available online, and 
provide a structured way to access them. (126 votes) 

DEC Response: We are actively looking at it. We have worked with 
some of these capabilities internally. The new CDROM (laser disk 
system) offers interesting possibilities. The HELP files under Version 
4.0 VMS are greatly expanded, and are a step in that direction. 

2. DEC should provide a sophisticated test formatter, with 
things such as multiple fonts, proportional spacing, math/- 
Greek, and macros (along the lines of formatters like 
and Scribe). (117 votes) 

DEC Response: We are evaluating a course of action in this impor¬ 
tant marketing area. We have worked with a number of such systems 
(like TjrjX and Scribe) internally, and are tracking the technology. 

3. DEC should add the complete “Block DO” and “Block CASE” 
constructs to VAX-Fortran. (92 votes) 

DEC Response: Portions of these constructs are already implemented 
in VAX-Fortran V4.0. We may implement further features in V5.0, 
and would expect to comply with the Fortran standard in this area, 
once it becomes finalized. 
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4. All VAX compilers should support a /check s arguaent.count qual¬ 
ifier (that checks to make sure the number and types of ar¬ 
guments passed match). (92 votes) 

DEC Response: Should all languages support this? Would it be some¬ 
thing that should be done at link time, rather than compile time, so 
that all calling sequences can be checked? We are interested in such 
a capability but have questions about how it could be effectively im¬ 
plemented in the Common Language Environment. 

5. DEC should market a general programmer's workstation. (79 

votes) 

DEC Response: We are evolving towards that, with the VAXstation 
II. We need to know more what you think a programmer’s workstation 
should consist of. 

6. DEC should provide an automated Documentation Control 
Manager. (79 votes) 

DEC Response: We’re not sure what this means. CMS will store 
any ASCII file, and we use that internally to control our documents. 

7. DEC should provide a “Lint”-like tool for VAX C. (78 votes) 

DEC Response: We are very aware of the need for a Lint-like ca¬ 
pability. We are interested in C portability issues. The /std=port 
compile option does a lot of checking. We will take a look at doing 
more, but will probably approach the solution from the DEC philoso¬ 
phy of providing tools that are multi-lingual, vs. a separate Lint-like 
tool for every different compiler. 

8. DEC product brochures should contain more technical in¬ 
formation about actual capabilities and requirements for a 
language/tool. (76 votes) 
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DEC Response: We are aware of the need and interested in solv¬ 
ing it. We have many different types of product literature; one of 
our biggest problems is how to ensure that we have a complete and 
up-to-date mailing list, so that the information actually reaches you. 
The Electronic Store is starting to make tool demos available on line. 

9. DEC should provide on-line CAI (Computer Aided Instruc¬ 
tion) classes for all new software tools. (71 votes) 

DEC Response: CAI courses are produced by Educational Services 
at DEC; they feel that CAI courses are not appropriate for technical 
people; they should be aimed more towards non-technical types. They 
are expensive to develop, and must justify themselves as a product. 

10. DEC should provide more complete implementation of the C 
rimtime library and closer compatibility of functions such as 
vfork() to the UNIX implementation. (69 votes) 

DEC Response: Version 2 of C has a lot more of the capability you 
are requesting. We are aware of the need and try to do as much as 
possible. 

11. DEC should provide software tool support for software de¬ 
sign. (68 votes) 

DEC Response: We are very interested in this topic, and are for¬ 
mulating ideas about how to meet this need. We would be very 
interested in hearing about the methodologies you use and would like 
to see supported. 

12. DEC should provide more emulation of the UNIX environ¬ 
ment on VMS. (68 votes) 

DEC Response: We are continuously working to enhance the C run 
time library and DEC/Shell, and plan to continue this activity. 

13. DEC should provide a problem report database tool that 
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is integrated with DEC/CMS and DEC/Test Manager. (67 

votes) 

DEC Response: This is something we are interested in. It relates 
to the concept of an overall “Configuration Management” tool. We 
have given sessions in this area at the last few Symposia. We are still 
working out all the details of what a configuration management tool 
would cover; but problem reports would obviously be one aspect. 

14. DEC should provide a tool to generate the dependencies file 
for MMS. (65 votes) 

DEC Response: We’re like to solve this problem - it is the most 
requested enhancement for MMS. We would like such a tool to also 
work on software outside the Common Language Environment, which 
makes it a much more complicated problem. However, we do have 
some ideas about how it might be solved. 

15. DEC should provide a configuration control manager. (63 

votes) 

DEC Response: We are very interested in this, and are working on 
concepts for it in advanced development right now. 

16. DEC should support GKS to level 2. (63 votes) 

DEC Response: We have plans to do this. 

17. DEC should provide a description of all tools in on-line help, 
even if they’re not licensed on the system, so people know 
what’s available and what the general capabilites for each 
tool are. (63 votes) 

DEC Response: It’s a good idea, but we have some questions about 
implementation details. It would require quite a bit of logistical 
manuevering to get it to happen. We plan on exploring this idea 
further. 
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LTSIG Wishllst 
for Anaheim 


Hello - My name is Alan Rizzuto, 1 am your new wishlist 
coordinator for the LTSIG. Some of you my have seen my name in the 
newsletter or may have met me at New Orleans. I am replacing A1 
Folsom who is publishing this newsletter now. 

I would like to take this opportunity to acquaint you with 
what .a wishllst is. If you already know what the wishllst is, I 
would like to explain the Importance of it to you and the other 
members of the SIG. 

The wishlist is our (leaders of the SIG) method of finding 
out the needs of each of the members of the SIG. The two areas of 
help that the wishlist provides is: what can the leadership of the 
SIG do for you the member, and what can DEC do to help you 
accomplish your task more efficiently. 

The most important part of the wishlist is YOUR involment in 
the wishlist. Each time we present the wishlist for voting (twice 
a year, before each symposia), we will be asking YOU for your 
Ideas on what should be on the wishllst. The only way that the 
wishllst can be totally effective is if YOU the member put your 
Ideas into the wishlist. 

The wishllst is then voted upon by the complete membership, 
which gives us a view of what all of the members feel about a 
given issue. The items that recieved the most votes (top ten) from 
the membership are then responded to by the leadership of the SIG 
for SIG related issues and most importantly DEC responds to the 
DEC related Issues. This allows you the member input to both DEC 
and the leadership of the SIG. 

On the following page you will find a form that should be 
used to write your wishlist entry. The wishlist will be published 
in the next issue of the newsletter. Please feel free to copy the 
form and send me as many items that you would like to see on the 
wishlist. 

If you have any questions or would like to contact me for any 
reason you can reach me at the following address or phone number 
between the hours of 0830 and 1700 Eastern Standard Time. 

Alan Rizzuto 

EMC Systems Inc. 

P.0. Box 534 

Cockeysvllle, Md. 21030 

(301) 628-8167 

Please send the forms in as soon as possible so that your 
item will appear in the wishllst. 


Thankyou, 

Alan Rizzuto 
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L&T Spring 1985 Wishlist Questionaire 


Name: _ 

Address: 

City, State ZIP: 
Phone: _ 


Check the one most appropriate choice: 

□ Interested in Languages and Tools 

□ User of Languages and Tools 

□ User of Languages and Tools, and interface with DEC developers 


Wishlist Question is directed toward: 

□ Languages and Tools SIG 

□ DEC 


Type(s) of Operating Systems: 


Type(s) of Hosts: 


Wishlist Question: 


44 





Printed in the U.S.A. 


"The Following are trademarks of Digital Equipment Corporation" 


ALL-IN-1 

Digital logo 

RSTS 

DEC 

EduSystem 

RSX 

DECnet 

IAS 

RT 

DECmate 

MASSBUS 

UNIBUS 

DECsystem-10 

PDP 

VAX 

DECSYSTEM-20 

PDT 

VMS 

DECUS 

P/OS 

VT 

DECwriter 

Professional 

Work Processor 

DIBOL 

Rainbow 



Copyright ®DECUS and Digital Equipment Corporation 1985 
All Rights Reserved 

The information in this document is subject to change without notice 
and should not be construed as a commitment by Digital Equipment 
Corporation or DECUS. Digital Equipment Corporation and DECUS assume 
no responsibility for any errors that may appear in this document. 

POLICY NOTICE TO ALL ATTENDEES OR CONTRIBUTORS "DECUS 
PRESENTATIONS, PUBLICATIONS, PROGRAMS, OR ANY OTHER 
PRODUCT WILL NOT CONTAIN TECHNICAL DATA/INFORMATION 
THAT IS PROPRIETARY, CLASSIFIED UNDER U.S. GOVERNED BY 
THE U.S. DEPARTMENT OF STATE'S INTERNATIONAL TRAFFIC IN 
ARMS REGULATIONS (ITAR )." 

DECUS and Digital Equipment Corporation make no representation that 
in the interconnection of products in the manner described herein will 
not infringe on any existing or future patent rights nor do the de¬ 
scriptions contained herein imply the granting of licenses to utilize any 
software so described or to make, use or sell equipment constructed in 
accordance with these descriptions. 


It is assumed that all articles submitted to the editor of this newsletter 
are with the authors' permission to publish in any DECUS publication. 
The articles are the responsiblity of the authors and, therefore, DECUS, 
Digital Equipment Corporation, and the editor assume no responsibility 
of liability for articles or information appearing in the document. The 
views herein expressed are those of the authors and do not necessarily 
express the views of DECUS or Digital Equipment Corporation. 



i 


STATUS CHANGE 

Please notify us immediately to guarantee 
continuing receipt of DECUS literature. Allow 
up to six weeks for change to take effect. 

( ) Change of Address 

( ) Please Delete My Membership Record 

(I Do Not Wish To Remain A Member) 

DECUS Membership No:_ 

Name:_ 

Company: _ 

Address:__ _ 


State/Country:... 

Zip/Postal Code:_ _ 


Mail to: DECUS - Attn: Subscription Service 
219 Boston Post Road, BP02 
Marlboro, Massachusetts 01752 USA 
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